fix(account-status-lifecycle-test): read resource-level status for SDK compatibility - #102
Merged
luisina-santos merged 2 commits intoJul 22, 2026
Conversation
…ust deprecated trait The account-status-lifecycle-test read user status only from the deprecated UserTrait annotation (`UserTrait_Status_Status`). In baton-sdk versions that moved status to a resource-level attribute (`Status_ResourceStatus`), a connector that sets only the resource-level status leaves the trait status unset, and the SDK defaults an unset trait status to STATUS_ENABLED. As a result the test always read STATUS_ENABLED and disable verifications failed even when the account was correctly disabled. get_user_status now reads both locations, prefers the resource-level value (normalized from RESOURCE_STATUS_* to the trait form STATUS_*), and falls back to the trait value only when no resource-level status is present. This keeps the action compatible with connectors built against any baton-sdk version. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
agustin-conductor
approved these changes
Jul 21, 2026
…esource Addresses review feedback: explicitly call out that baton-sdk v0.19.0 (ConductorOne/baton-sdk#996) is where status moved from the deprecated UserTrait field to the resource-level attribute. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mateoHernandez123
approved these changes
Jul 22, 2026
ggreer
approved these changes
Jul 22, 2026
ggreer
left a comment
ggreer
left a comment
Contributor
There was a problem hiding this comment.
Oops. Whenever baton-sdk is upgraded in all the connector repos, we can simplify this.
luisina-santos
deleted the
luisinasantos/status-lifecycle-test-resource-status
branch
July 22, 2026 18:14
mateoHernandez123
added a commit
to ConductorOne/baton-coupa
that referenced
this pull request
Jul 23, 2026
Revert the bare --invoke-action=disable_user/enable_user steps back to the account-status-lifecycle-test reusable action, now on @v4. v4 reads resource-level status (ConductorOne/github-workflows#102), so it is compatible with this PR's WithStatus -> WithResourceStatus migration and restores the strong assertion that the synced status actually flips, instead of only checking the actions run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mateoHernandez123
added a commit
to ConductorOne/baton-coupa
that referenced
this pull request
Jul 23, 2026
…upa Connector (#47) * feat(coupa): add license profile trait to license resources * fix(coupa): sync UserLicenseResponse struct with license projection The setLicensePath projection requests three additional license fields (clmAdvancedUser, coupaNaviAiAgentUser, intakeUser) but UserLicenseResponse was not extended to match, so those flags were silently dropped when the PUT response was unmarshalled. Add the three bool fields with dashed JSON tags (clm-advanced-user, coupa-navi-ai-agent-user, intake-user) to keep the struct in sync with what the API actually returns. Verified against the live tenant that Coupa returns these fields in dashed form (matching the struct tags), not the camelCase used in the projection. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(coupa): build license grant from entitlement resource in Grant The Grant provisioning path built the returned *v2.Grant from the principal (user) instead of the license, emitting user:<uid>:assigned for an entitlement the user type does not define. This made provisioning grants inconsistent with the sync path, which correctly emits license:<lid>:assigned:user:<uid>. Build the grant from entitlement.Resource so it mirrors Grants(). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(coupa): restore account-status-lifecycle-test via v4 action Revert the bare --invoke-action=disable_user/enable_user steps back to the account-status-lifecycle-test reusable action, now on @v4. v4 reads resource-level status (ConductorOne/github-workflows#102), so it is compatible with this PR's WithStatus -> WithResourceStatus migration and restores the strong assertion that the synced status actually flips, instead of only checking the actions run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
account-status-lifecycle-testaction reads user status only from the deprecatedUserTraitannotation (UserTrait_Status_Status, e.g.STATUS_ENABLED).Recent
baton-sdkversions moved status to a resource-level attribute (Status_ResourceStatus, e.g.RESOURCE_STATUS_ENABLED). When a connector migrates toWithResourceStatus(...)and sets only the resource-level status:NewUserTraitdefaults an unset trait status toSTATUS_ENABLED.So the test always reads
STATUS_ENABLEDfrom the trait, and disable verifications fail even when the account was correctly disabled:(Hit while migrating
baton-lookeroff the deprecated trait options — the connector builds and disables correctly, but this shared test couldn't observe the resource-level status.)Fix
get_user_statusnow reads both locations and:resource.status.status, normalizingRESOURCE_STATUS_*→ the trait formSTATUS_*.status.statusonly when no resource-level status is present.*_UNSPECIFIEDas absent, so the unreliable defaulted trait value never masks a real resource-level status.Downstream comparisons (
is_user_enabled, summaries) are unchanged — they still compare againstSTATUS_ENABLED/STATUS_DISABLED.This keeps the action compatible with connectors built against any baton-sdk version (trait-only, resource-only, or both).
Validation
Verified the jq logic against all shapes:
STATUS_DISABLED✅ (wasSTATUS_ENABLED❌)STATUS_ENABLED✅STATUS_DISABLED✅STATUS_ENABLED✅STATUS_DISABLED✅unknown✅bash -npasses on the script.🤖 Generated with Claude Code